Subject: Hypercom feature matrix

From: [email-masked] (David Matusow)
Date: Tue, 8 Jun 93 12:43:45 -0400

The following is the DLS feature matrix for Hypercom.  We are most 
interested in the use of a mixture of topologies between the DLS 
switches.  This would allow the customer to mix-and-match 
topologies/DLCs on an as needed basis.  This freedom would be good for 
both the vendor and customer.

=========+===+
         |HYP|
=========+===+
flow ctrl| X |
=========+---+
NT 2.1   | X |
=========+---+                                                                
Ethernet | X |                                                                
=========+---+                                                                
priority | X |                                                                
=========+---+                                                                
COS      | X |                                                                
=========+---+                                                                
cap exch | X |                                                                
=========+---+                                                                
conform  | X |                                                                
=========+---+                                                                
SDLC     | X |                                                                
=========+---+                                                                
channel  |   |                                                                
=========+---+                                                                
TG       |   |                                                                
=========+---+                                                                
directory| X |                                                                
=========+---+                                                                
transport| X |                                                                
=========+---+                                                                
security | X |                                                                
=========+---+                                                                
NN integ | X |                                                                
=========+---+                                                                
MIB      | X |                                                                
=========+---+                                                                

Notes and Comments:
        1. Company abbreviations that need explanation:
                HYP             Hypercom, Inc.

        2. Feature abbreviations:
                flow ctrl       flow control
                NT 2.1          support for NT 2.1 SDLC devices
                Ethernet        support for Ethernet media type
                priority        traffic prioritization
                COS             subarea class of service
                cap exch        capabilities exchange
                conform         interoperability and conformance testing
                SDLC            greater support for SDLC devices
                channel         support for channel as a DLC
                TG              subarea transmission groups
                directory       directory support for configuration info
                transport       support for alternate transport (non-TCP/IP)
                security        self explanatory (?)
                NN integ        DLSw integration with APPN Network Node
                MIB             definition of a DLSw MIB
----------------------------------------------------
Notes on previous notes to matrix

>       3. Support for Ethernet entails support of the Spanning Tree Protocol
>          (Shannon Nix, Netlink).

Why should ethernet require support for spanning tree; this should/may 
be required by all protocols.  This should be a protocol-independent 
feature; there should be no significance to ethernet. 

>       4. Possible addition: LPDA2, but that might be best covered in the
>          SNA MIB Working Group at the IETF.  Sync Research hasake their implementation more attractive to 
customers, but it doesn't seem that it should be of interest to the DLS 
group.

>       5. Conformance Testing should be performed by an outside agency
>          (Bob Nowak, Siemens).

Strong agreement!  What, obviously, it needed is a testing suite.  
Though testing would be done by an outside agency, the suite should be 
agreed upon and published.  I hope that this statement DOES mean that 
the suite would be developed by the group.

--------------------
Other area (or expansion of existing ones)

1.  DLC independence

    It seems that the DLC (tr, ethernet, SDLC, etc.) should be outside 
    of the area of this group.  If we do our jobs correctly, this layer 
    should be independent.  This would allow the DLS DLC to be modified 
    as needed by the customer and as supported by the vendors.  Thus, if 
    frame relay is the best choice in one case, X.25 in another, and 
    TCP/IP in another, this can be done without effecting the 
    architecture.  At most, it seems that this should be a tower built 
    upon the base that we are designing. 

2.  Capabilities (sorry if this is repetition of known areas)

    This is one of the more interesting areas, as this allows the 
    architecture to be constant, while allowing implementors to separate 
    themselves.  Areas of interest may include:

    -   APPN-like XID (this could be of great interest if SNA is used as 
        the DLC) 

    -   capacity indicators, such as number of circuits that can be 
        supported 
    
    -   local recovery capabilities.

3.  The DLC between the switches may get driven from an incoming request 
    for service.  This could be advantageous if the DLC is time-costly.  
    The dropping of the DLC if there is no usage could also be 
    investigated.  Or should these be left to an implementor?
-----------------------------------

Thanks,
David Matusow
Hypercom